The present invention generally pertains to transport of MPEG video streams from a network server to a media client. More particularly, the present technique for efficiently performing fast forward and fast rewind operations in response to a user's request. The technique uses buffering and interim transport of MPEG video files contained in these streams to avoid network delays associated with transition between files.
With the explosive popularity of computers and the internet, there is a growing interest in using networks to transport multi-media selections such as video and audio material, to remote locations. Interactive television (ITV), movies on demand, and other multi-media push technologies for example, are among the more promising applications.
Transporting video and audio material typically involves transferring video files from a server over a network which services a number of individual media clients. ITV servers, for example, use a collection of computing, storage, and communications equipment to transfer these files when providing interactive video services. A particular interactive service may require more than one server in order to be implemented, or a server may implement more than one service. The servers generate compressed audio and video streams in standard formats that require decompression only at the location of the media client. Consumers' remote control button-press signals are carried back to the server for interpretation by the service application. In this type of configuration, the media client can view a movie or other type of video much in the same fashion as one would operate a standard VCR.
Due to the size of most video files, it is necessary to stream the files from the server to the media client over the network. There are, however, some data network protocol issues of concern when streaming video. One issue relates to the fact that digital video data streams are very sensitive to delays and transmission errors, which can be caused for various data networking reasons. Also, streaming digital video data usually requires transmission rates which are beyond the bandwidth capabilities of current residential access network technology.
Given a movie stored on disk as an MPEG-based normal play file, an express file represents a shortened version of the normal play file such that only the frames corresponding to fast forward (or fast rewind) play of the movie are stored in the express file. MPEG stream data therefore can include normal play, reverse express, and forward express files which are abbreviated herein as 1X, RX, and FX files, respectively. The idea behind using express files is to save on network and disk bandwidth. Since one frame for every n frames is actually shown to the user during display of fast forward and fast rewind video, it is a waste of bandwidth to ship all the data to the client, including the frames that will be discarded. Express files are therefore built by scanning the normal play file, and selecting every nth frame.
In order to make the selection easier, express files may store in them only the I-frames that appear in the normal play file. I-frames contain information resulting from intraframe coding techniques which exploit the spatial redundancy existing between pictures. In the case of express files, the choice of the value of n will therefore be limited to the size of the group of pictures of the normal play file.
In order for express files to work, some link information must be maintained between the three types of video files. This information helps transition between video files in response to the media client's commands. Each video file has an associated database file with a record for the other video files. For example, the 1X file has a database file with a 1X-FX record, and a 1X-RX record. The database files contain the necessary link information for transition between files. Each record of the file contains fields carrying link pointers to the other database files. The link pointers in the database files are indexed by the frame number of each stream. Once the user requests another file by pressing the fast forward, fast rewind, or play button, the link information allows determination of the next stream that needs to be retrieved and displayed, based on the current frame number in the current stream.
Although the link information guarantees the display of the appropriate sequence of frames, it does not guarantee that the frames will be displayed at the correct time. Simply put, although the correct frames are selected, these frames may experience significant delays before being displayed due to network delays. An undesirable "hiccup" on the screen of the media client is the result of such a delay.